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Abstract 


This document provides guidelines for applying or extending the MPLS 
or GMPLS ((G)MPLS) protocol suites and clarifies the IETF’s (G)MPLS 
working groups’ responsibility for the (G)MPLS protocols. This 
document is directed to multi-vendor fora and Standards Development 
Organizations (SDOs) to provide an understanding of (G)MPLS work in 
the IETF and documents the requisite use of IETF review procedures 
when considering (G)MPLS applications or protocol extensions in their 
work. This document does not modify IETF processes. 
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Les 


Introduction 


The MPLS and GMPLS technology is developed in two main tracks in the 
IETF. "MPLS" refers to the work done for packet switched networks, 
while "GMPLS" refers to the efforts to apply the MPLS protocols to 
all types of networks including packet and non-packet technologies. 


Though GMPLS by definition is a superset of MPLS, the term "(G)MPLS" 
is used in this document to indicate both of these tracks. A 
terminology section that covers the use of terms and concepts used in 
this document is found in Section 2.6. 


[RFC4775] discusses procedural issues related to the extension or 
variation of IETF protocols by other SDOs. It provides the 
guidelines and procedures to be used by other SDOs when considering 
the requirements for extensions to IETF protocols. [RFC4775] 
recommends that major extensions to, or variations of, IETF protocols 
only take place through normal IETF processes or in coordination with 
the IET 


Hy 


The (G)MPLS protocol families were developed within the IETF and 
constitute significant protocol suites within the Internet standards. 
The (G)MPLS suites of protocols have become popular for a number of 
new applications and deployment scenarios. There have been concerns 
with regards to other technology fora developing, using, and 
publishing non-standard protocol extensions as a standard not only 
for use within their community, also for wider use by the industry. 
Especially concerning is the development of extensions, without 
consulting the (G)MPLS working groups, which are in conflict with 
efforts on-going in the (G)MPLS working groups, and then presented to 
the (G)MPLS working group as 'fait accompli’. 


The definition and publishing of non-standard extensions by other 
fora, without IETF review, and outside of the IETF publication 
process, regardless if rationalized as limited to use among fora 
vendors, or limited to a particular application, or rationalized as 
allowing timely demos, has the unfortunate potential to hinder 
interoperability and increase complexity of the protocol, sows 
confusion in the industry, and circumvents the Internet standards 
process that exists to ensure protocol implementability. As 
described in [RFC4775], non-standard extensions, including 
experimental values, are not to be portrayed as industrial standards 
whether by an individual vendor, an industry forum, or a standards 
body. 


This document clarifies the IETF’s MPLS and Common Control and 
Measurement Plane (CCAMP) working groups’ roles and responsibilities 
for the (G)MPLS protocols and documents the requisite use of, and how 
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to apply, the [RFC4775] procedure of using the IETF review processes, 
[RFC2026] and [RFC2418], for fora wishing to apply or extend the 
(G)MPLS protocols. Use of the IETF review processes will ensure an 
open process for protocol development and ensure a non-harmful 
evolution for these IETF protocols, which will benefit the larger 
industry users’ community. IETF itself cannot enforce a forum to use 
the (G)MPLS change procedure, though any forum not following it, when 
applying for IANA assignment or IETF publication, will be delayed 
until this procedure has been completed. 


This document does not change the formal IETF standards process as 
defined in [RFC2026] and [RFC2418]. It is consistent with the 
general procedures for protocol extensions defined in [RFC4775] and 
shows how they are applied in the case of (G)MPLS. Any procedures 
described in this document are to be implemented in a way consistent 
with these three documents. They MUST be used when other SDOs and 
fora wish to propose (G)MPLS changes. They SHOULD be used internally 
within the IETF unless the changes concerned are considered non- 
controversial by the responsible Area Director(s) (e.g., covered by 
the working group charter), in which case other aspects of the normal 
IETF standards process cover the necessary procedures. 


dees Document Source 


This document is the joint work of the IETF Routing Area Directors, 
the IETF MPLS and CCAMP Working Group Chairs, and the IETF’s liaisons 


to the ITU-T. It had considerable review and comment from key 
members of the ITU-T who have given their time and opinions based on 
experience for which the authors are grateful. The IESG has also 


provided valuable input to arrive at the process documented here. 
The acknowledgements section lists those whose contributions have 
been particularly helpful. 


1.2. Conventions Used in This Document 


Although this document is not a protocol definition, the key words 
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 
are to be interpreted as described in RFC 2119 [RFC2119]. This usage 
is chosen to make the steps and procedures completely clear. 


2. Overview of (G)MPLS within the IETF 
This section describes the key IETF working groups developing the 


(G)MPLS technology and provides information on IETF working groups 
using the (G)MPLS technology. 
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It should be remembered that the IETF environment is highly dynamic. 
Working groups and whole areas come and go. The overview of the 
relevant working groups within the IETF is only a snapshot in time. 


2.1. IETF Working Groups Developing (G)MPLS Technology 


Two working groups in the IETF’s Routing Area are responsible for 
work related to developing the (G)MPLS technologies: Multiprotocol 
Label Switching (MPLS) working group and the Common Control and 
Measurement Plane (CCAMP) working group. 


The following sections provide brief overviews of the chartered work 
of these two IETF working groups. 


2.1.1. Multiprotocol Label Switching Working Group 


The Multiprotocol Label Switching (MPLS) working group is responsible 
for standardizing the base technology that uses label switching, and 
for describing the implementation of Label Switched Paths (LSPs) over 
various packet and frame-based link level technologies. The working 
group charter includes procedures and protocols for the distribution 
of labels between routers, as well as encapsulations, operation and 
management, traffic engineering, and multicast considerations. 


This document assumes that the MPLS working group remains the 
chartered authority on MPLS technologies, but notes that the IETF may 
appoint another working group (refer to [RFC2418]) to handle specific 
extensions or changes to the protocols. Further, in the event that 
the MPLS working group completes its work and is closed, the IETF 
will use the non-working group standards track document process 
(described in [RFC2026]) using designated experts from the community 
[RFC2434] for the MPLS protocols. 


2.1.2. Common Control & Measurement Plane Working Group 


The IETF Common Control and Measurement Plane (CCAMP) working group 
coordinates the work within the IETF defining common control and 
measurement planes for ISP and SP core tunneling technologies. This 
includes, but is not limited to, defining signaling protocols and 
measurement protocols such that they support multiple physical path 
and tunnel technologies using input from technology-specific working 
groups such as the MPLS working group. It also includes the 
development of protocol-independent metrics and parameters for 
describing links and paths that can be carried in protocols. 


The technology that the CCAMP working group focuses on is called 
Generalized MPLS (GMPLS), indicating that CCAMP addresses a 
generalized technology, where labels are defined in such a way that 
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they will be compatible with the technology over which the data is 
transported. While the MPLS working group focuses on packet- and 
frame-switched technologies, the CCAMP working group work focuses on 
common methods across a broad spectrum of switching technologies 
including packet and frame technologies. In this respect, GMPLS can 
be viewed as a superset of MPLS. 


The procedures in this document assume that the CCAMP working group 
remains the authority on GMPLS technologies, but acknowledges that 
the IETF may appoint another working group (refer to [RFC2418]) to 
handle specific extensions or changes to the protocols. Further, in 
the event that the CCAMP working group completes its work and is 
closed, the IETF will use the non-working group standards track 
document process (described in [RFC2026]) using designated experts 
from the community [RFC2434] for the GMPLS protocols. 


2.1.3. MPLS and CCAMP Division of Work 


From time to time, the MPLS and CCAMP working groups decide to divide 
work between themselves in a way that does not strictly follow the 
split between the working groups as defined in the working group 
charters. This is the case, e.g., for P2MP TE LSPs, where the MPLS 
working group is specifying requirements and base technology for all 
of the (G)MPLS technologies. 


An entity or individual that wishes to propose extensions or changes 
to (G)MPLS should first decide to which working group (MPLS or CCAMP) 
it will bring the proposal. However, the MPLS and CCAMP working 
group chairs, in conjunction with their Area Directors, may redirect 
the proposal to another working group. 


2.2. Other (G)MPLS Technology-Related Working Groups 


Problem statements and requirements for (G)MPLS technology have been 
produced by several working groups in addition to the MPLS and CCAMP 
working groups. IETF working groups are defined for the management 
of specific tasks by their charter. Their charter defines their 
role, relationship with other working groups, and the applicable 
procedures to follow when extensions to (G)MPLS may be needed. This 
section provides an overview of the (G)MPLS-related groups and their 
responsibilities. Additional information describing the working 
groups and their charters is available on the IETF web pages. 


The IP over Optical (IPO) working group and the Internet Traffic 
Engineering working group (TEWG) are examples of working groups which 
focus on problem statements and requirements for (G)MPLS to be 
considered by the (G)MPLS working groups. These working groups have 
not specified any protocols. 
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The Bidirectional Forwarding Detection (BFD) working group, also may 
use the (G)MPLS protocols and mechanisms. The BFD working group is 
chartered for requirements evaluation and protocol specification 
related to BFD. If the working group needs to extend or change the 
(G)MPLS protocols, the procedures specified by its charter and the 
IETF’s standard processes are applicable. 


The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have 
been chartered to specify a limited number of solutions for Provider 
Provisioned VPNs. Both working groups are in the Internet Area. 

Much of the work of the L2VPN and L3VPN working groups does not 
include specifying new protocols or extensions to existing protocols. 
Where extensions are needed, the procedures as specified by their 
charters and the IETF’s standard processes are applicable. 


The Layer 1 VPN (L1VPN) working group is chartered to specify 
mechanisms necessary for providing Layer 1 VPN services 
(establishment of layer 1 connections between CE devices) over a 
GMPLS-enabled transport service-provider network. Protocol 
extensions required for L1VPN will be done in cooperation with MPLS, 
CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That 
is, the L1VPN working group will not develop GMPLS protocol 
extensions in isolation, but will develop requirements and propose 
extensions that will be reviewed and approved by the (G)MPLS working 
groups. 


The Pseudo Wire Emulation End to End (PWE3) working group is a 
working group that may use the (G)MPLS protocols in its 
specifications. Should the PWE3 specifications require extension or 
changes to the (G)MPLS protocols, the procedures as specified by its 
charter and the IETF’s standard processes are applicable. 


2.3. Organizations Outside the IETF 


A number of standards development organizations (SDOs) and industrial 
forums use or reference the (G)MPLS protocols in their 
specifications. Some of these organizations have formal or informal 
liaison relationships with the IETF [RFC4052]. The IETF exchanges 
information with these organizations about what is happening on both 
sides, including plans and schedules, using liaison statements 
[RFC4053]. More details about the cooperation relationship between 
the IETF and the ITU-T can be found in [RFC3356]. 


The procedures in this document are applicable to all organizations 
outside the IETF whether or not they have formal liaison 
relationships with the IETF. If any organization outside the IETF 
has a requirement for extensions or modifications to the (G)MPLS 
protocols then the procedures in this document apply. 
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3. Overview of (G)MPLS Change Process 


This is a non-normative section, as it is intended to provide a high- 
level view of [RFC4775] procedures for protocol extensions. 
Application of these procedures for (G)MPLS are defined in detail in 
Section 4. 


Whenever there is reason to believe that a particular problem may be 
solved by use of or extensions to the (G)MPLS protocols, a 
communication using the formal liaison process, or, for a forum 
without a formal relationship, an informal communication, may be used 
to discuss the problem with the IETF ([RFC4052] and [RFC4053]). 
Collaboration with the IETF in the early discussion phase will 
facilitate a timely understanding of whether the problem has already 
been solved, may be outside the scope of the (G)MPLS protocols, or 
may require more investigation. 


Whenever any extension or change to the (G)MPLS protocols is desired, 
a problem statement and/or requirements statement must be produced 
and must be submitted to IETF as an Internet-Draft. When the 
requirements come from an external organization, informal 
communications, such as e-mail to working group mailing lists, is 
strongly encouraged as it facilitates timely and cooperative work. 
However, if desired, the Internet-Draft, containing the 
requirement (s), may be submitted to the working group using a formal 
liaison statement. IETF’s response to the request will be given as a 
reply to the liaison. This use of formal communication reduces the 
risk of confusing an individual participant's opinion for that of the 
group as Can happen on mailing lists, though it does introduce a more 
lengthy communication cycle. If there is no formal liaison 
relationship, a communication may be sent directly to the (G)MPLS 
working group, a relevant Area Director, or the IESG. 


The IETF, through the appropriate Area Director, and the chairs of 
the MPLS and CCAMP working groups for (G)MPLS related work, will 
direct the requirements draft to an appropriate working group for 
assessment and comment. This process may require communication and 
discussion for clarification, but the IETF undertakes to perform the 
assessment in a timely manner. 


In assessing the requirements statement I-D, the IETF may determine: 


- that the requirements can be satisfied without modifications to the 
(G)MPLS protocols 
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- that the requirements are not sufficiently general or there is not 
sufficient interest to do a standards-track solution to warrant a 
Standards-track change to the (G)MPLS protocols 


- that the requirements justify a standards-track change to the 
(G)MPLS protocols 


- that the requirements might not be possible to satisfy without 
violating the (G)MPLS architecture in a way that would harm the 
(G)MPLS technology 


- that the requirements should be combined with other requirements to 
solve a more general problem or solve the same problem in a more 
flexible way. 


In the event that the IETF agrees to develop a solution, the IETF 
will set milestones that would result in timely delivery of the 
solution in a timely manner. If the IETF rejects the requirements, 
this will only be done with clear explanation and full discussion 
with the source of the requirements. 


The solutions that are developed within the IETF may be sourced from 
external organizations and presented for review, discussion, 
modification, and adoption as Internet-Drafts. Such solutions drafts 
may be presented to the IETF in advance of the completion of the 
requirements work, but all solutions will be processed through the 
normal IETF process with other proposed solutions. Solution drafts 
are adopted as an IETF working group draft when the requirements are 
stable, and not before the protocol-responsible working group has a 
charter item to cover the solutions work. It is strongly recommended 
for interested parties to start informal discussion in the IETF, as 
early as possible, and to co-author in the IETF’s work. It is not 
recommended for the source forum to continue to work on solutions in 
parallel with on-going work in the IETF. If the protocol-responsible 
working group is unable to accept the work (e.g., due to current work 
load), the IETF processes ([RFC2418]) provide alternate options for 
ensuring the work is completed. 


4. MPLS and GMPLS Change Process 


This section defines the (G)MPLS change process and the rules that 
must be followed in order to make extensions or changes to the 
(G)MPLS protocols. The language of [RFC2119] is used in order to 
clarify the required behavior of the IETF and the originator of the 
change request. It is consistent with the general procedures for 
protocol extensions defined in [RFC4775]. Any interpretation of 
procedures described in this document and their implementation are to 
be in a way consistent with [RFC4775]. 
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Anyone who intends to use one of the existing (G)MPLS protocols, but 
thinks that it will not satisfy their needs MUST use the procedures 
described in this document. They SHOULD be used internally within 
the IETF unless the changes concerned are considered non- 
controversial by the responsible Area Director(s) (e.g., covered by 
the working group charter), in which case other aspects of the normal 
IETF standards process apply. Changes or extensions to the (G)MPLS 
protocols MUST NOT be made by any other mechanism. The IETF MUST NOT 
endorse any publications (including RFCs, whether on the Standards 
Track, Informational, or Experimental) that change or extend the 
(G)MPLS protocols except for those that arise through the correct 
execution of the procedures in this document. The IETF MUST NOT 
endorse any IANA action that allocates (G)MPLS protocol codepoints, 
except as a result of actions arising from the correct execution of 
the procedures in this document. 


4.1. Flow Diagram 


Figure 1 gives a visual overview to illustrate the roles of a (G)MPLS 
requirements evaluation working group (REWG) and (G)MPLS protocol 
solutions working group (PSWG). The figure presents two alternatives 
for a requestor: (1) contact the IETF early in the problem definition 
phase (preliminary investigation), or, (2) later, with a requirements 
statement. The figure is for illustration only; it does not contain 
all of the possible interactions and IETF procedure alternatives. 

The text in the subsequent sections describes the process. 
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Figure 1: Change Process Overview 
4.2. Description of Process Stages 


This section describes how the (G)MPLS change process works, what is 
expected from individuals or organizations that want to extend or 
change the (G)MPLS protocols, and the responsibilities of the IETF. 
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4.2.1. Preliminary Investigation 


This step is OPTIONAL, and is intended to provide a lightweight way 
to "feel out" the IETF’s position on a proposal without going to the 
effort of writing an Internet-Draft. The intention is to determine 
whether the problem has been examined already, whether the problem is 
in scope for the IETF, and whether solutions are already known. 


Although the preliminary investigation phase is optional it is 
RECOMMENDED that the originator of any requirements consult and 
discuss the issues concerned as early as possible to avoid any wasted 
effort, and the preliminary investigation phase provides a mechanism 
to do this. 


Useful discussions may be held at this stage in order to ensure that 
the problem statement and requirements statement Internet-Drafts 
contain the right material. This step is described as lightweight 
because no Internet-Draft is required and because the step largely 
involves offline discussions. However, it may be the case that this 
step involves considerable technical discussions and may, in fact, 
involve an extensive, substantive exchange of ideas and opinions. 


This step SHOULD be carried out informally on the mailing list of the 
REWG or on the Routing Area discussion mailing list, and MAY be 
initiated by any individual, group of individuals, external 
organization, or IETF working group. 


When an external SDO has a liaison relationship with the IETF, it MAY 
carry out this step using a formal liaison. The liaison SHOULD be 
sent to the designated liaison manager who is responsible for 
forwarding them to the IESG who will assign a Responsible AD. The 
initiators of the liaison SHOULD make themselves available for 
discussion on the selected mailing list. If a formal liaison is 
used, the IETF will respond using the procedures of [RFC4053]. 


At this stage, a problem statement I-D MAY be produced to help 
further the discussions and to clarify the issues being addressed. 


A possible outcome of this preliminary investigation is that the 
requirements and problem are understood, but agreed to be out of 
scope for the IETF. Alternatively, it may be that the problem can be 
solved with existing protocols. The full list of outcomes from the 
preliminary investigation phase are similar to those for the 
requirements statement evaluation phase described in Section 4.2.2, 
but the requirements statement evaluation phase that allows wider 
IETF community participation in developing a complete requirement set 
MUST form part of the process if the IETF is to consider to develop 
protocol solutions. The process cannot move direct from the 
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preliminary investigation phase to the development of solutions 
unless the working group agrees (e.g., the problem is minor). 


4.2.2. Requirements Statement Evaluation 


Before the IETF can formally pronounce on requests to change or 
extend the (G)MPLS protocols, a requirements statement I-D MUST be 
written per [RFC2026]. 


The requirements statement I-D MUST be introduced by the authors to 
the IETF through an email to the REWG mailing list, to the Routing 
Area discussion mailing list, or by a formal liaison from an external 
SDO which will result in the IETF introducing the requirements 
statement I-D to the REWG mailing list. If the requirements 
statement I-D is brought to the IETF through a formal liaison, the 
initiators of the liaison SHOULD make themselves available for 
discussion on the designated IETF mailing lists. 


After discussion on the IETF mailing lists, the responsible Area 
Director MUST decide whether the requirements will be formally 
evaluated by the IETF, and MUST deliver a response to the per 
[RFC4053] and [RFC4775]. If a formal liaison was not used, the 
response SHOULD be delivered to the appropriate contact as listed on 
the communication. 


The IETF response MUST be sufficiently explanatory to inform the 
requesting organization of what, if anything, the IETF has decided to 
do in response to the request. The following list is provided to 
illustrate possible responses: 


a. Requirements not understood. Further discussion is required. 


b. Requirements understood, but judged to be out of scope for the 
IETF. In this case, the originator of the requirements can work 
on requirements and solutions and will not be impeded by the 
IETF. The IETF may request to be kept informed of progress. 


c. Requirements understood, but no protocol extensions are needed. 
It may be desirable for the external SDO to cooperate with the an 
IETF working group in the production of an Applicability 
Statement Internet-Draft. 


d. Requirements understood, and the IETF would like to develop 
protocol extensions. This results in execution of the rest of 
the procedure, described below. The requirements raised in the 
requirements statement I-D may be combined with other 
requirements to produce more general extensions or changes to the 
(G)MPLS protocols. 
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4.2.3. Working Group Procedures 


In many cases, the problem covered by the requirements statement I-D 
will fall within the scope of the existing charter of a working 
group. In this case, the responsible Area Directors will designate 
the working group as the REWG and pass the requirements statement I-D 
to the working group for evaluation. If the problem is not covered 
by an existing charter, other alternatives (refer to [RFC2418]) may 
be used, e.g., rechartering, BOF, chartering a new working group. 


If the IETF modifies its prior decision to accept the work, the IETF 
MUST communicate this to the requestor in a timely manner. 


4.2.4. REWG Evaluation of the Requirements Statement I-D 


The objective of the REWG evaluation process is to determine a clear 
and complete statement of the requirements for changes or extensions 
to the (G)MPLS protocols. This will necessitate normal IETF working 
group procedures in the REWG and MAY include the generation of 
revisions of the requirements statement I-D in cooperation between 
the members of the REWG and the original authors of the requirements 
statement I-D. 


The originators of the requirements statement I-D MUST make 
themselves available to discuss the work on the REWG mailing list. 
If this does not happen, the chairs of the REWG MAY determine that 
there is insufficient support for the work and MAY reject the 
requirements statement I-D. 


The output of the REWG will be either: 

- a completed requirements statement I-D that has been accepted by 
working group consensus within the REWG and has passed through 
working group last call; 


or 


- a rejection of the requirements using the response procedure as 
described in Section 5. 


4.2.5. AD Evaluation of Completed Requirements Statement I-D 


As with all Internet-Drafts produced by a working group, the ADs will 
review the completed requirements statement I-D produced by the REWG. 
The ADs will then pass the document to the IESG for review. If 
charter changes are needed or a new PSWG needed, the appropriate 
process will be followed. 
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4.2.6. IESG review of Requirements Statement I-D and PSWG Charter 


As with all Internet-Drafts, the IESG will review and make a decision 
on the progression of the requirements statement I-D. 


If the IESG rejects the requirements statement I-D, it will generate 
an appropriate response to the working group (and, if needed, to the 
originator of the request). 


The IESG will review any proposed charter changes for the PSWG or, if 
needed, consider alternatives. This might include the formation of a 
new working group specifically to work on the solutions. 


4.2.7. Solutions Work 


The appropriate PSWG will start work on solutions following the 
normal IETF process. 


Solutions I-Ds MAY be prepared externally (such as within an external 
organization) or within the IETF, submitted to the IETF for draft 
publication using the procedures of [RFC2418], and introduced to the 
PSWG for consideration. Such I-Ds MAY be submitted at earlier stages 
in the process to assist the REWG in its development and discussion 
of the requirements, but no I-D will be formally considered as a 
solutions I-D until the PSWG has a charter item that covers the work 
and the REWG chairs are confident that the requirements are stable. 


The IETF makes no guarantees that an externally produced solutions 
I-D will form the basis of the PSWG solutions I-D, but the PSWG MUST 
consider such an I-D for review and revision as a possible solution 
I-D, using the same open procedures ([RFC2418]) as for any individual 
submission. The IETF’s procedures are based on open and fair 
participation, and thorough consideration of technical alternatives. 


Interested parties (both implementers and users) of the SDO 
originating the request are strongly encouraged to participate in the 
PSWG to ensure appropriate interest is shown in the solutions work 
and to provide timely solutions development. The IETF’s work, as 
that of any SDO, is driven by its participants. The IETF is an open 
community and any SDO requesting IETF solutions work SHOULD ensure 
appropriate industry interest in the work, or the IETF MAY 
discontinue its support of the work. Appropriate communication of 
the discontinued work will be made to the originator of the request 
(if the originator is reachable). 


The final development of the solutions I-D is subject to the normal 
working group review, consensus, and last call within the PSWG. 
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Where the requirements originated from an external organization, the 
PSWG SHOULD regularly communicate its progress using a formal liaison 
process if one exists. This communication SHOULD also be used to 
request review input and comment on the development of the solutions 
I-D. The solutions I-D MUST be communicated to the originating 
organization during working group last call for final review against 
the requirements. When the solutions I-D is complete (normally upon 
completing working group last call and/or on entering the RFC 
Editor’s queue) the PSWG MUST inform the originating organization of 
the completed solution. 


5. Rejecting the Requirements Statements I-D 


Rejection of the requirements statements is a sensitive matter for 
the authors of the requirements and MUST be handled with full 
disclosure and explanation by the IETF. All working group actions 
are taken in a public forum ([RFC2418]). 


The requirements can be rejected at various stages of the process as 
described in the previous sections. The person or group that makes 
the rejection is responsible for generating an explanation of the 
rejection and MUST follow the [RFC4775] process. Possible reasons 
for rejection are described in this section. 


5.1. Reasons for Rejection 


The requirements statement I-D can only be rejected with full 
disclosure by the IETF. Possible reasons for rejection and possible 
next steps as described here. 


- Requirements not understood. Either during preliminary 
investigation or during evaluation of the requirements statement 
I-D, it was not clear what the requirements are, or what the 
problem being addressed is. 


This rejection forms part of an on-going communication and it is 
expected that the process will continue with further iterations. 


- Out of scope for the IETF. Many stages of this process may 
determine that the requirements are out of scope for the IETF. In 
this case, the IETF MUST NOT constrain the authors of the 
requirements statement I-D from working on a solution. If any 
(G)MPLS changes are later identified, the requestor MUST reinitiate 
the (G)MPLS change procedure. 


- No protocols extensions or changes are needed. At some stage in 
the evaluation of the requirements it may become clear that they 
can all be met through appropriate use of existing protocols. In 
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this case, no further evaluation of the requirements is required, 
but the REWG MUST explain how the protocols can be used to meet the 
requirements and MAY cooperate with the authors of the requirements 
statement I-D in the production of an Applicability Statement 
Internet-Draft or a Profiles Internet-Draft that explains precisely 
how the existing protocols can be used to meet the requirements. 


- Insufficient support within the IETF. Although the work described 
within the requirements statement I-D is within scope for the IETF, 
and despite the support of the originators of the requirements 
statement I-D on the REWG mailing list, the chairs of the REWG have 
determined that there is insufficient support in the REWG to 
complete requirements statement I-D and initiate solutions work in 
the PSWG. In this case, the IETF MUST NOT restrict the authors of 
the requirements statement I-D from working on a solution. The 
solution (and/or IANA codepoints requested) SHALL be presented to 
the IETF’s (G)MPLS PSWG for review and possible publication as an 
Informational or Experimental RFC, and, pending IETF review 
results, the IETF SHALL NOT block applications to IANA for 
codepoints. If IANA codepoint assignments are required, the IANA 
Requirements prescribed for those assignments in the relevant RFCs 
MUST be satisfied. It is highly recommended for the SDO to 
encourage its participants to participate in the IETF work to 
ensure appropriate industry representation in the work. 


- Insufficient support for the work from the original requesters. If 
the authors of the requirements statement I-D do not make 
themselves available on the REWG mailing list for discussion of the 
requirements or do not contribute the completion of the 
requirements statement I-D, the chairs of the REWG MAY determine 
that there is insufficient support for the work and MAY reject the 
requirements statement I-D. In this case, the IETF MUST NOT grant 
permission for the work to be carried out in any other 
organization, and MUST NOT endorse the publication of any changes 
or extensions to the (G)MPLS protocols and MUST NOT instruct IANA 
to allocate any codepoints. The requirements may be reintroduced 
by starting the procedure again from the top. 


- Satisfying the requirements would break the technology. It is 
possible that an assessment will be made that, although the 
requirements are reasonable, it is not possible to satisfy them 
through extensions or changes to the (G)MPLS protocols without 
violating the (G)MPLS architecture in such a way as would break the 
(G)MPLS technology. In this case, a recommendation will be made 
that some other technology be used to satisfy the requirements. 

See Section 7 for further discussions of the protection of the 
integrity of the (G)MPLS technology. In this case, the IETF MUST 
NOT grant permission for the work to be carried out in any other 
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organization, and MUST NOT endorse the publication of any changes 
or extensions to the (G)MPLS protocols and MUST NOT instruct IANA 
to allocate any codepoints. 


5.2. Actions Required When Rejecting Requirements Statement I-Ds 


Upon rejection, the IETF MUST make a clear statement of why the 
requirements statement I-D has been rejected and what next step 
actions are acceptable (refer to Section 5.1). 


The communication of the rejection depends on the form of the 
original submission as follows. 


- If the requirements are brought to the IETF as a preliminary 
investigation (see Section 4.2.1) through an email exchange then 
the response MUST be made as an email response copied to an IETF 
mailing list so that it is automatically archived. 


- If the requirements are brought to the IETF as a preliminary 
investigation (see Section 4.2.1) through a formal liaison, the 
rejection MUST be delivered through a formal liaison response. 


- If a requirements statement I-D has been produced and discussed on 
an IETF email list, the response MUST be made as an email response 
and copied to the email list. 


- If a requirements statement I-D has been produced and brought to 
the IETF through a formal liaison, the rejection MUST be delivered 
through a formal liaison response. 


- If an IETF working group has been involved in the review or 
production of any Internet-Drafts for the requirements or for the 
solutions, the working group MUST be notified of the rejection and 
the reasons. 


The responsibility for the generation of the response lies with the 
person, people, or group that instigates the rejection. This may be 
the IESG, one or more Area Directors, one or more working group 
chairs, or a designated expert [RFC2434]. In the case of the use of 
a liaison relationship, the IETF’s liaison manager has responsibility 
for ensuring that the procedures in this document, and particularly 
the rejection procedures, are followed. 


5.3. Appeals 
[RFC2026] contains additional information related to procedure 


disagreements and appeals. The rejection of a requirements statement 
I-D as described in Sections 5.1 and 5.2 may be appealed in the event 
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it is disputed and cannot be reversed by direct discussion between 
the parties. The conflict resolution and appeal mechanism is 
documented in [RFC2026]. 


6. Abandonment of the Solutions I-D 


Once the solutions work has been started by the PSWG, it may be 
abandoned before completion. This can happen if the PSWG chairs 
determine that there is no longer working group support for doing the 
work. This could arise, for example, if no one (including the 
originators of the requirements statement I-D) is willing to 
contribute to the development of a solutions I-D. 


In the event that the solutions work is abandoned by the PSWG, the 
Area Directors responsible for the PSWG MUST be consulted. The 
originators of the requirements statement I-D MUST be informed that 
the work has been abandoned using a mechanism dependent on how the 
requirements were introduced (as discussed in Section 5.2). 


If the solution is abandoned in this way, work on solutions for the 
requirements MUST NOT be started in another forum. The status of 
extensions and changes to the (G)MPLS protocols with regard to the 
specific requirements returns to how it was before the process 
started. Any new examination of the requirements MUST commence at 
the top of the process. 


6.1. Appeals 


The abandonment of a solutions I-D may be appealed in the event it is 
disputed and cannot be reversed by direct discussion between the 
parties. The conflict resolution and appeal mechanism is documented 
in [RFC2026]. 


7. (G)MPLS Integrity and Ownership 


The (G)MPLS working groups are REQUIRED to protect the architectural 
integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS 
architecture with features that do not have general use beyond the 
specific case. They also MUST NOT modify the architecture just to 
make some function more efficient at the expense of simplicity or 
generality. 


The architectural implications of additions or changes to the (G)MPLS 
protocols MUST consider interoperability with existing and future 
versions of the protocols. The effects of adding features that 
overlap, or that deal with a point solution and are not general, are 
much harder to control with rules and risk impacting the protocol as 
a whole. Therefore, to minimize operational and technical risks to 
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the (G)MPLS technology, IETF processes SHALL be followed for any 
requests on extensions to (G)MPLS protocols. With respect to (G)MPLS 
protocols, the (G)MPLS PSWG is the chartered "owner" of the (G)MPLS 
protocol, as long as the working group exists. All changes or 
extensions to (G)MPLS MUST first be reviewed by the (G)MPLS PSWG. 


8. Security Considerations 


All requirements statement I-Ds MUST give full consideration to the 
security impact of the proposed additional features or functions. 
All solutions I-Ds MUST consider the impact on the security of the 
protocol extensions and to the pre-existing protocol. 


This documents does not itself introduce any security issues for any 
(G)MPLS protocols. 


The IETF process is itself at risk from denial of service attacks. 
This document utilizes the IETF process and adds clarity to that 
process. It is possible, therefore, that this document might put the 
IETF process at risk. 


Therefore, provided that the number of requirements statement I-Ds is 
not unreasonable, there will be no significant impact on the IETF 
process. The rate of arrival of requirements statement I-Ds MAY be 
used by the IESG to detect denial of service attacks, and the IESG 
SHOULD act on such an event depending on the source of the 
requirements statement I-D and the perceived relevance of the work. 
The IESG might, for example, discuss the issue with the management of 
external organizations. 
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10. IANA Considerations 


This document makes no specific requests to IANA for action. The 
procedures described in this document assume that IANA will adhere to 
the allocation policies defined for the (G)MPLS codepoint registries 
and that the IETF will not endorse allocation of codepoints from 
those registries except where work has been carried out in accordance 
with the procedures described in this document. 
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